IBIS Macromodel Task Group Meeting date:10 August 2021 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis Jared James Google: Zhiping Yang Intel: Michael Mirmak Kinger Cai Alaeddin Aydiner Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Todd Bermensolo * Rui Yang Luminous Computing David Banas Marvell Steve Parker Micron Technology: * Randy Wolff Justin Butterfield Missouri S&T Chulsoon Hwang Siemens EDA (Mentor): * Arpad Muranyi SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Walter to send BIRD213.1 draft4 to ATM for people to review. - Done. - Fangyi to send BIRD211.3 draft4 to ATM for people to review. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the August 3rd meeting. Ambrish moved to approve the minutes. Randy seconded the motion. There were no objections. ------------- New Discussion: BIRD211.3 draft4: Randy had sent out a version of the draft with some additional comments. Fangyi shared Randy's version so the group could review the comments. Randy described some of the comments and changes: "redriver" -> "Redriver" throughout the document In the section to be added at the end of 10.2.3, Randy asked why we enumerate a a list of 3 items. He asked whether we should just turn those 3 items into a paragraph. Bob said he thought the list was clearer. Randy suggested that we typically have a semicolon at the end of the sentence preceding a list. Fangyi added "as described below" to the end of the sentence preceding the list. At the top of page 6 of the BIRD, the paragraph says: ... by convolving the "GetWave Input" with a filter ... Randy said we should define "GetWave Input", as it's the first time we've used a phrase in such a way. Ambrish said he thought the entire paragraph could be removed. He said the two items that follow the paragraph could simply be added to the bullets that follow the subsequent paragraph. Fangyi said we have to be careful about combining too much. The first paragraph is talking about how the EDA tool may determine a filter that represents the model's equalization. The second paragraph describes avoiding a double-counting scenario, which may require the use of the filter response described in the first paragraph. Fangyi said all Dual models are "double-counting" in the sense that both the AMI_Init and AMI_GetWave apply the model's equalization effects. Walter said it is intended behavior that AMI_Init applies the model's equalization to its input IR and AMI_GetWave applies the model's equalization to its input waveform. Curtis and Ambrish said "double-counting" in the second paragraph (also from page 198 in IBIS 7.0) referred to something different. In the case in which the Tx model was a Dual model and the Rx model was Init Only, a tool that naively applied the time-domain flow, and used the output of Rx AMI_Init to create a proxy AMI_GetWave for the Rx, might end up counting the effects of the Tx model twice. This is because the Tx model's effects, as returned by Tx AMI_Init, are already in the IR input to the Rx's AMI_Init. So, they are also contained in the output of Rx AMI_Init. To get around the issue, the IBIS 7.0 text suggested the tool could avoid using Tx GetWave, or it could use deconvolution to extract the Rx's equalization from the output of Rx AMI_Init. Now, with this new BIRD, we are also codifying the "unit impulse response as a crosstalk column" method of determining the model's equalization. Fangyi said everything in the second paragraph really only applies to step 6d of the time-domain flow (i.e., the Tx Dual and Rx Init-Only case). He suggested we remove the paragraph and add the bullet items to 6d. Ambrish agreed, and they said 6d should list 3 possible approaches for the tool: 1. Not utilize the Tx AMI_GetWave 2. Use deconvolution to determine the impulse response of the Rx filter and apply it by convolution to create a proxy GetWave 3. Pass a unit impulse response into Rx AMI_Init as a crosstalk column, use the output of that column to represent the Rx filter, and apply it by convolution to create a proxy GetWave The group agreed with this approach. Several people commented that the existing "double-counting" lead-in paragraph, which had been intended to describe the potential problem, caused more confusion than it was worth. They noted that step 6d of the normal time-domain flow already properly explains the flow such that it avoids any "double-counting" issues. As we were at the top of the hour, discussion will have to continue next week. Arpad noted that we had not gotten through all of Randy's comments. Ambrish asked Fangyi to consider whether the Retimer sections had to be modified at all. He said if the new Tx_Impulse_Input parameter is irrelevant to Retimers, then he would prefer to minimize changes in the existing IBIS 7.0 text. - Ambrish: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 17 August 2021 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives